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ABSTRACT 


This document presents pertinent Information regarding the evaluation 
and certification of sensitive software applications in the NASA 
environment. The evaluation and certification of sensitive 
applications on a periodic basis is a sound management practice and 
Is responsive to the requirements of QMB Circular A-71, Transmittal 
Memorandum No. 1. The evaluation process includes definition of 
security objectives, assessment of security feasibility, analysis of 
technical specifications, and a security posture evaluation, which 
Includes the performance of vulnerability, threat scenario, and 
safeguard analyses . 
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EXECUTIVE SUMMARY 


As a part of an overall computer security effort, NASA has an 
on-golng program to ensure the continuity of operations and data 
Integrity of sensitive applications. 0MB Circular A-71, Transmittal 
Memorandum No. 1, requires a periodic certification of such 
applications. 

The purpose of this document Is to provide guidance for a Center 
management evaluation and certification process which will evaluate 
the adequacy of safeguards for existing sensitive applications. The 
concepts presented in this report are Intended to provide guidance 
for Initial certification as well as for the recertification of 
existing sensitive applications. Recertification procedures will 
essentially be the same as certification procedures, however, they 
will be performed by an Independent party, i.e. not the principal 
user. Guidance for the certification of new application systems will 
be addressed In a subsequent report. The procedures provided In this 
report may be modified by the NASA Centers to conform to their 
Internal requirements. 

Key action Items for the evaluation and certification process 
Include: 

e Identification of the Degree and Scope of Application 
Sensitivity 

Functional Requirements 
Objectives 

Technical Specifications 
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e Definition of Computer Security 
e Definition of Computer Security 
e Definition of Computer Security 
e Security Posture Evaluation 
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• Evaluation Report 


• Certification Statement 


The material presented in the safeguard evaluation sections of the 
evaluation and certification process is based on information provided 
in FIPS PUB 73 and FIPS PUB 65. It is recommended that the reader 
obtain copies of these publications for reference. 
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INTRODUCTION 


A comprehensive computer security program Includes several 
complementary areas such as: ADP facility risk analysis, 

personnel security, management awareness, and computer security 
considerations during ADP procurements. 

Another aspect of an overall computer security program Is an 
activity to ensure the continuity of operations and data 
Integrity of sensitive applications. Central to this activity 
Is the notion of certification for new and periodic 
recertification for existing sensitive applications. 

0MB Circular A-71, Transmittal Memorandum No. 1, "Security of 
Federal Automated Systems," (Reference 1) contains the 
requirement for certification and periodic recertification of 
new and existing applications within the Federal sector. In 
addition, management Instructions have been Implemented 
NASA-wide and have established the requirement for certification 
of sensitive applications at each Center. 

The purpose of this report Is to present a guideline for a 
Center management evaluation and certification process which 
will evaluate the adequacy of safeguards for meeting the 
security requirements for existing sensitive applications. 
Certification action formally documents responsibility for the 
adequacy of application safeguards. Recertification will 
consist of Identical evaluation and certification procedures 
performed by an Independent organization. This report will 
discuss the major Issues and concepts which form the basis for 
an Initial certification of existing sensitive applications. 
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The evaluation and certification process outlined in this 
dociunent <d.ll not address the following areas: 


• Personnel Security . Personnel Security will be 
reviewed by a separate program under the NASA security 
office. However, the security classification of 
individuals associated with the sensitive application 
should be reviewed and any Inconsistencies noted and 
reported to the Data Processing Installation-Computer 
Security Official (DPI-CSO) and the NASA security 
office. 

• Physical Security . The physical security of the DPI 
and terminal locations will be addressed as part of the 
DPI risk analysis. 

• Operating System Security . The security of the 
operating system will be separately reviewed. However, 
the sensitive application evaluation should consider 
password control and protection aspects. 

• Privacy Act Compliance . The evaluation/certification 
process described herein does not specifically respond 
to the Privacy Act and controls relating to Privacy Act 
compliance will be separately reviewed. However, there 
may be significant overlap between this process and the 
review of a Privacy Act system to ensure adequate data 
protection. 


This report makes numerous reference to material in FIPS PUB 
73; FIPS PUB 65; MURE Technical Report (MTR)-79W00445, 

An Overview of ADP Risk Analysis ; and MTR-81W302, 

Security Planning for Computer Applications (References 3, 4, 5, 
6) . It is recommended that the reader obtain copies of these 
publications. 
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The guidance provided by this report may be modified by the 
HA.SA centers to conform to their Internal procedures. The basic 
concepts, however, are considered an Integral part of the 
evaluation and certification process and should not be 
neglected . 


1 . 1 Evaluation and Certification Action Items 


The evaluation and certification process for existing sensitive 
applications within NASA Is Illustrated In Figure 1-1. The key 
action Items for the evaluation and certification process 
Include: 


1. D/avelop the Project Plan . A project plan serves as 
the primary management tool In directing the evaluation 
and certification process. 

2. Identify the Degree and Scope of Application 
Sensitivity . Review all aspects of the application to 
Include Its attributes, features, functions, and data 
types to Identify the degree and scope for the 
application. 

3. Define Computer Security Functional Requirements . A 
user statement of requirements related to computer 
security Is based on specific security objectives and 
the extent of security control automation that Is 
feasible for the application. The test for 
appropriateness Is related to the degree and scope of 
sensitivity for the application. 

4. Define Computer Security Technical Specifications. A 
statement of specific functions or features the 
software should exhibit to satisfy security functional 
requirements. Examples Include: 

• password control at the record level 

• control totals generated at specific points I 

• manual review procedures j 


1-3 


Develop Project 
Plea 


Ievlev criteria eatabliahed in 
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In Section 3.2 of thia report. 
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thia report. 


Evaluation perfocaed through 
a Vulnerability Analyala . 
e Threat Scenario Analyala 
e Safeguarda Analyala 
leference Section 3.4 and 3.5 
of thia report. 
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Section 4 of thia report. 


FIGURE 1-1 
EVALUATION/CERTIHCATION PROCESS 
FOR EXISTING SENSITIVE APPLICATIONS 
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• check digits 

• edit criteria 
e limit checks 


5. Evaluate Existing Safeguards . Examination of an 
application's vulnerabilities In conjunction with 
threat scenario determination provides the basis for 
security control evaluation. These analyses will 
validate the adequacy of the safeguards and Isolate 
those Instances ^ere additional controls are 
required. Additional controls are developed In a 
safeguards analysis. 

6. Evaluation Report . This report provides an overall 
evaluation of the control posture for the application. 
In addition, the report will also Identify -Inherent 
weaknesses and provide recommendations for 
certification decision action. 

7. Certification Statement . The certification statement 
formally documents the responsibility for Initial 
certification of an existing application within the 
scope determined by the evaluation and certification 
process. 


1.2 Overview of the Report 


Section 2 of this document discusses evaluation and 
certification management concepts.. Section 3 describes a 
suggested approach for the evaluation process and Section 4 
presents general criteria for certification decision action. 
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2, EVALUATION AMD CERTIFICATION MMiAGEMEHT 


2»1 Roles and Responsibilities 


The basis for certification management Is provided through the 
NASA security management functions described In NASA Appendix J, 
"Computer Resources Management", NHB 2410.1. Proposed 
management roles and responsibilities In the evaluation and 
certification process are defined as follows: 

Center Computer Security Official (Center CSO) 

e Overall responsibility for the evaluation and 
certification process at the center level 

e Provides assurance and guidance for performance of the 
project plan 

Data Processing Installation Computer Security Official 
(DPI CSO) 

e Works with the Application CSO In the development and 
definition of security objectives and controls 

e Assumes the role of an Application CSO for those 
applications which have more than one primary user 

Application Computer Security Official (Application CSO) 

e As the primary functional user, defines project plan 
for the evaluation and certification process 

e Determines the sensitivity of the application 

e Works with the DPI CSO In the development and 
definition of security objectives and controls 

• Signs the Certification Statement 
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2,2 Project Plan 


The initial step in the certification management process is a 
project plan. The project plan serves as a management tool in 
directing the evaluation and certification process for an 
existing application and as such documents the approach taken 
for the evaluation process. The project plan should: 


a Identify the particular application. 

a Identify all baseline documentation uhlch addresses 
security Issues and controls. Suggested documentation 
Includes : 

- functional requirements 

- design specifications 

- maintenance manual 

> operations manual 

- user manual 

- flow charts 

- sample I/O documents 

- management policies and procedures 

a Designate roles and responsibilities of the 

organizations and individuals who will compose the 
evaluation and certification team. Typically these 
could ' Include representatives from the following 
organizations : 

- user office 

- software maintenance 

- DPI operations 

- audit 

a Define or determine the degree and scope of sensitivity 
a Identify or define the security objectives 
a Describe application characteristics 

- Identify application characteristics Including the 
size and complexity 
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• Provide preliminary assessment of security posture. 
State the areas of emphasis Including: 

- greatest threats, exposures, controls, etc. 

" findings of risk analysis, audits, etc. 

e Provide a schedule of events for the evaluation and 
certification process 


e Define support requirements and manpower 


3 


EVALUATIOH PROCESS 


For existing systems. It may be necessary to define certain 
elements l^illclt In the overall application, but idilch were not 
reduced to writing In the early phaaes of the life cycle. These 
elements are application aensltlvlty, aecurlty feasibility, 
security objectives, and security technical requirements. 

3.1 Application Sensitivity 

FIPS PUB 73, Section 2.3 "Examples of Sensitive Systems", 
presents six application groupings which have similar security 
problems. The reader should review the description of security 
concerns for these applications. Although not exhaustive, the 
examples do Illustrate the relationship between type of 
sensitivity and security objectives. In some Instances, only a 
portion of an application system may be sensitive, l.e., the 
application may be sensitive only under specific circumstances 
or In certain operational modes. Application sensitivity may be 
also confined to a subsystem. Therefore, it Is necessary to 
consider all aspects of the application. It Is suggested that 
Appendix J, Section 502, NHB 2410.10, be reviewed for specific 
NASA criteria. 

3.2 Security Requirements 

Verification of security requirements Is based on security 
feasibility and security objectives for the application as 
discussed below. 
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3«2.i Security Feasibility 

For existing systems « It Is necessary to review the extent of 
automated controls Implemented within the application software 
or those associated with managerial or operational procedures. 
Section 4.3 of MIR-81W302, Security Planning for Computer 
Applications (Reference 6) provides general criteria for this 
step In the evaluation process. Specific feasibility criteria 
are specified In NBS FIBS PUB 73, Section 5.1, which Include 
computer security provision for: (1) source data accuracy, (2) 

user Identity verification, (3) restricted Interfaces, (4) 
separation of duties, and (5) facility security. If the above 
criteria cannot be affirmed for the application, establishment 
of viable security controls by management may not be possible. 


3.2.2 Security Objectives 

Since the occurrence of an undesirable event during the 
processing of an application may result In a variety of 
detrimental effects, specific security objectives for the 
particular application must be determined. A few of these 
adverse events taken from NBS FIPS PUB 31, Section 1.3.2, are 
listed below: 

e Fire 
e Flood 

e Power Failure 
e Hardware Failure 
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• Intrusion 

• Theft 

FIPS PUB 73, Section 2, describes some general categories of 
security objectives and Illustrates their relationship with 
particular types of undesirable events. 

Security objectives are Identified by classifying undesirable 
events In terms of the Immediate effect rather than ultimate or 
final effect on data associated with the application. Examples 
of Immediate effects of these events Include: 

e Modification of data 
e Disclosure of data 

e Unavailability of data or system services 

Specific security objectives resulting from these effects are 
respectively: 

e Data Integrity 
e Data Confidentiality 
e ADP Availability 

Objectives may also be classified through the analysis of 
accidental or deliberate acts. Accidents and errors occur more 
frequently than deliberate acts and should receive the primary 
focus of attention. 

It is Important to remember that the Implementation of a 
specific control In meeting a specific objective may have an 
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adverse effect on ocher objectives. If possible* security 
objectives oust be ranked or weighted for the particular 
application. The determination of security objectives will also 
Influence the security technical specifications for safeguard 
laq>lementatlon as well as risk ^issessment performance. 

3.3 Security Technical Specifications 

Security technical specifications are determined by review of 
the following areas: 

• Application Interfaces 
e Operational Procedures 

e Management Considerations 
e Sensitivity and Asset Value of Data Objects 

• ^rror Tolerance 

Appropriate application documentation should be reviewed to 
assess the adequacy of technical specifications for security 
controls In these areas. Suggested action Items for each of 
these areas are described below. 


1. Application Interfaces . Identify each job component or 
other automated systems that provide Input data to the 
application system or support Its operation. Conversely, 
all job components and applications that are supported by 
the application system should also be Identified. Review 
the nature of the Interaction between each application job 
component. Suggested job components Include: 

- data collection at the source 

- data entry 

- data base administration 


3-4 




- output dissemination 

- Implication software maintenance 

- documentation 

- data archival storage 

- operations 

- outputs 

- system programming 

- Internal reviews and audit procedures 

- security planning and control procedures 

2. Hanagement Considerations . Identify and define the 
separation of duties within each Job component or 
operational procedure as well as availability requirements 
for the application. Availability requirements should 
clearly establish limits on the maximum length of 
Interruption for the application or Its potential frequency 
of use. 

3. Operational Procedures . Identify and define the 
responsibilities of the Individuals who Interact with the 
application through each Interface. Constraints on use must 
be Identified if a certain degree of security Is to be 
enforced. This principle should also be applied to other 
application systems which Interact with the current 
application. Critical operations should be identified. 

4. Sensitivity of the Data Objects . Determine the sensitivity 
and asset value of data objects associated with the 
application. These data objects are the data as seen by the 
user rather than the data processed by the application 
software. Security requirements for data objects should be 
validated with respect to objectives of data lnte;jrlty « 
confidentiality , availability , and fraud prevention . 

5. Error Tolerance . Reliability and validity of the data and 
the Intended objectives of the applications constitute the 
primary considerations In assessing the error tolerance for 
the application. Requirements for maintaining potential 
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error levelf to within this tolerance must be addressed as 
part of th0 security requirements. 

FIPS PUB-73 (Section 3 and Section 6.1) provides a 
comprehensive discussion on security controls and functional 
security requirements. While these examples are not exhaustive, 
those provided are sufficient to determine technical security 
specifications. The precision and method of Implementation of 
the technical specification Is Influenced by the factors of 
security feasibility and security objectives. 

3.4 Security Posture Evaluation 

For those applications where security requirements have been 
adequately defined, an assessment of the security posture that 
considers the application software and Its data should be 
performed. This assessment will Include a determination of 
vulnerabilities and threats. The likelihood of a threat 
happening vs. the possible annual loss If It does occur will 
also be determined. Safeguards will be suggested based on the 
likelihood and annual loss potential. Typical vulnerabilities 
pertaining to thtreats of 

a Disasters 
s Delay 

a Erroneous Input 
a Erroneous output (program errors) 
a Theft 
a Vandalism 
a Fraud 

a Information Disclosure 
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should be considered In the assessment. FIPS PUB 65 and 
MTF,-79W00445, An Overview of ADP Risk Analysis (Reference 5) 
provides guidance In this area. 

3.4.1 Vulnerability Analysis 


The first step In the evaluation of controls Is based primarily 
on the application security objectives In conjunction with 
Inherent vulnerabilities. Together, the vulnerabilities and 
security objectives establish the basis for the threat scenario 
analysis. A vulnerability may be thought of as a 'hole* In the 
line of defense against threats. It Is the absence or 
Ineffectiveness of a safeguard. Threats will reduce a system's 
Integrity, confidentiality, or availability. See Figure 3-1 for 
an Illustration of this concept. 

Although an application's vulnerability to some types of 
threats may vary, certain vulnerabilities are common to most 
sensitive applications. A detailed checklist for common types 
of vulnerabilities may be found In the ^pendlx of FIPS PUB 65. 

A work sheet Is provided In Appendix A to help with this 
analysis . 

3.4.2 Threat Scenario Analysis 

Threat scenarios serve to validate a security control's 
effectiveness against an application's vulnerabilities and 
security requirements. A threat Is a circumstance which may 
cause loss or harm to the system, e.g., the employment of a 
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nOURE 3-1 

VULNERABILITY-THREAT RELATIONSHIPS 


convicted embezzler as a bank teller. Figure 3-1 Illustrates 
how threats penetrate defenses through vulnerabilities and 
Figure 3-2 Illustrates the effect of successful penetration. 


In addition, threat scenarios also serve to Isolate those 
aspects of an application which lack effective safeguards. 
Guidance for this evaluation technique Is presented In 
references 7 and 8. 

An effective threat scenario analysis team Is composed of 
personnel who are familiar with all aspects of the application 
Interfaces described In Section 3.4. Not more than ten 
personnel should be selected for the team. Once the team 
members have been Identified, the team leader should develop a 
short statement that defines those application aspects which 
will be considered for threat scenario analysis. The statement 
should also Include a list of vulnerabilities and security 
objectives. A few possible or probable threats for the 
application should be provided as examples and a full meeting 
for the team should also be scheduled. The preliminary material 
should be sent to each member of the team well in advance of the 
first team meeting. 

Actual threat scenario development is accomplished through a 
series of Informal team meetings. Each meeting should be 
scheduled for a minimum of two and one-half hours. It Is 
recommended that at least two meetings be held. Each meeting 
should begin with a discussion and review of preliminary 
material or material provided from the previous meeting. Flip 
charts may be used with all pages put on full display once 
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filled. Whenever possible, the team should attempt to determine 
the probability of a particular threat occurrence. However, If 
a probability cannot be Immediately assigned. It Is desirable to 
categorize the threat occurrence In general terms such as high, 
medium, or low. Safeguards which counter each threat should be 
developed by the team and listed for the threat. 


Finally, the threats must be ranked. The ranking of threat 
scenarios may be acconq>llshed through consensus action by the 
threat scenario team. See Appendix A for threat scenario 
worksheets. 

3.5 Safeguards Analysis 

Safeguards should be developed for the vulnerabilities listed 
in the vulnerability analysis. Use the safeguards developed In 
the threat scenario analysis and those developed from the 
vulnerability analysis to conduct the safeguard analysis. The 
safeguards should be ranked into three categories for 
Implementation . 


f C ritical - These measures reduce a serious 

vulnerability to a threat. Implementation should take 
place Immediately to establish or maintain the proper 
level of security. 

s Necessary -These measure reduce a less serious 
vulnerability to a threat. This control should be 
Implemented but the need Is less immediate than for 
critical safeguards. 

o Desirable - These measures provide extra levels of 
security and are discretionary. 


3-11 


rwrfsmra ?5» 3s 


Figure 3-3 shove hov safeguards plug "holes” in the line of 
defense. 

The ranking of safeguards using the above categories provides a 
basis for nanagement decisions for an Implementation time 
frame. A cost benefit analysis or a return on Investment 
determination should also be done to assist In the selection of 
safeguards for implementation. A return on Investment 
determination Is based on the difference between the expected 
loss before the Implementation of the safeguard, less the 
expected loss after the Implementation of the safeguard, divided 
by the cost of the safeguard. In many cases obtaining 
quantitative data may not be feasible, and a qualitative 
evaluation nay be necessary. In these cases, a high, medium, or 
low value may be used for these elements. After safeguards have 
been ranked and benefits assessed, recomnendatlons for 
management decisions can be made. 

3.6 Evaluation Report 

The primary purpose of the evaluation report Is to document the 
evaluation and subsequent certification process for an 
application and to serve as the basis for the certification 
statement. It also establishes the degree of confidence to be 
placed in the evaluation process and Its findings. 

The report should accurately reflect the existing control 
posture for the applications. The major portion of the findings 
should discuss the results obtained from the vulnerability, 
threat scenario, and safeguard analyses. The report will also 
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Identify any serious application shortcomings which may require 
further study such as a modification In operational procedures. 
The evaluation report Is maintained In the security file for the 
sensitive application. A suggested outline for the evaluation 
report is presented In Appendix B. 
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CERTIFICATION STATEMENT 


The certification statement represents the final step In the 
evaluation/certification process for an existing application. 

The Application CSO Is responsible for making the certification 
decision. The decision process Involves Interpreting the 
recommendations made In the evaluation report and In some cases, 
defining controls that must be Implemented In order to authorize 
continued operation. The decision process may be influenced by 
the operational Impact of Implemented safeguards or by Increased 
costs Incurred due to restrictions Imposed on the application's 
functions. 

Typical restrictions which may affect continued operation 
Include : 


e Addition of procedure controls 
e Separation of duties 

e Restriction to process data of reduced sensitivity 

e Restriction on the number of user Individuals 

e Removal of unauthorized access In a dial-up mode by 
utilization of security software packages 

e Removal of application subsystem or component functions 
software 


A suggested format for the certification statement is presented 
In Appendix C. 


4-1 


APPENDIX A 


THREAT SCENARIO ANALYSIS - ASSISTANCE AND CONSIDERATIONS 

The following pages provide: 

1. An outline for the threat team meetings. 

2. Specific threat tea>j considerations. 

3. An example work sheet to help the team develop scenarios. 

4. Example work sheets to help In the vulnerability, threat 
scenario, and safeguard analysis. 
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A.l OUTLINE FOR INITIAL THREAT TEAM MEETING 


A. 1 . 1 Agenda 

• Purpose of threat teams 
e Steps Involved 
e War Stories 
e Vulnerability Analysis 
e Threat Scenario Discussion 
s Determine Probability of Scenario Occurrence 
e Determine Ranking of Scenario 
e Wrap-up and Summary 

A»1.2 Primary Meeting 


e Confidential, to prevent disclosure of system 
vulnerabilities 

e Moderator uses flip charts to summarize as discussion 
occurs 

e Alternative: Each member summarizes the scenario and 

turns It over to the moderator for editing 
and It Is also summarized on-golng using a 
flip chart for the group. 

A. 1.3 Final Meeting 


e 


Meet again for one hour to go over transcript or 
write-up and Inject second thoughts. 


A. 2 SPECIFIC THREAT TEAM CONSIDERATIONS 


A, 2,1 Team Member Requirements 

• Knowledge of the Systesi 

e Confidence and personal security to allow the 
Individual to participate without fear 

e Imagination 

e Outgoing personality 

A»2,2 Avoid These Members 

e Managers with a general overall responsibility who have 
little day to day contact with the specifics of the 
operational system. 

• Persons new In their Job 
e Security Officers 

A. 2. 3 Overall Considerations 

e No more than 10 members for a team 
e 2 to 2^2 hour primary session 

A»2»4 Advantage of the Threat Team Approach 

e Realistic practical vulnerabilities 

• Low cost 

e Management awareness and Interest 

• Employee's willingness to participate (gaming) 
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• Integrates well 

e Accepted by management 

e Provides a basis for testing controls 


'< 

i 


I 

j 


A . 2 . 5 Disadvantages 

e Secrecy required (exposes weaknesses) 
e Skilled leader required 
e Not always methodical 
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EXAMPLE OF COMPLETED THREAT SCENARIO WORK SHEET 
A. 3 THREAT SCENARIO WORK SHEET 

1. What la attackad or coaproalaad In tha ayataa? 




2 . 


3. 


What vulntrablXltlai allov the attack? ^ , / * / 

jr/ ,xy\. [i cvc'ta.CC ptvckA^ ctr 

What aethoda could be used? 


C(ftiu^ X: xtu. ■h^a^jOL^&^ 

^UuXi ^6^ djJ^'CLC, 


danc (X'i^ 

dXc. 


4. What aafasuarda or controls can pravanc the lost? 

iUijL 

^ff^tc()aA.L. dc-Ci^, ^ 

5. What la the likelihood that thla acenarlo will work? 
(High* acdlua or Low) 

4i^L 

6. What la the lapact on the aaaeta If It doea %rork? 
(Order of oagnltude In dollarat l.e.* tena« hundreda, 
thouaanda, etc.) 

X/,cco< 


Reproduced from 
bes> available copy. 
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Saxesuard Sunma 


Propoaad Safaguarda 


/ <ii deytukvcL ^/UAO/ti. ^eciduxi^ 

■ in- / 

JptettduAcJ _ 

^CCuJia -t-/0 


Coac Banafit 
or Laval of 

Priority of Raturn on 

Safaguarda Invaatnant 




3 . Ki^^tOTK^ic 

JUU. ^cna^lA-^ fUtO 

t>h/t ^ 


-^nrintCL.- 




CUtfia^ 



'PtidccA/n^ 












Scenarios 

(A brief description) 


Proposed Safeguards 


Cost Benefit 
or Level 

Priority of of Return on 
Safeguards Investment 
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APPENDIX B 


SUGGESTED EVALUATION REPORT OUTLINE 


1 . Executive Summary 

2 . Introduction/Background 

3 . Evaluation Process 

3.1 Feasibility Assessment 

3.2 Security Objectives 

3.3 Security Specifications 

3.4 Security Posture Evaluation 

3.4.1 Existing Control Posture 

3.4.2 Vulnerabilities 

3.4.3 Threat Scenario Analysis 

3.4.4 Safeguards Analysis 

4 . lllecoimnendatlons 


Attachment A: 
Attachment B: 
Attachment C: 


Project Plan 

Proposed Certification Statement 
Threat Scenario Reports 


I 

i) 

I, 
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APPENDIX C 


PROPOSED CERTIFICATION STATEMENT FORMAT 

Based on the evaluation of (Sensitive Application) dated 
(Evaluation Report Date) , the security safeguards are deemed 
adequate for the application with restrictions or clarifications 
noted below, and to the best of my knowledge, meet all 
applicable federal policies, regulations, and standards. 


Signature Date 

(Application CSO) 
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